In `@apps/web/pages/api/webhook/app-credential.ts`:
- Line 31: Replace the unconditional call to
appCredentialWebhookRequestBodySchema.parse with a safe parse flow: call
appCredentialWebhookRequestBodySchema.safeParse(req.body), check the
result.success flag, and if false respond with a 400 (Bad Request) including the
validation errors; otherwise assign the parsed data to reqBody and continue.
Update references to reqBody and preserve existing handler logic so only invalid
bodies return early with a 400 and validation details.
- Around line 57-59: The decryption and JSON parsing of reqBody.keys using
symmetricDecrypt(...) and JSON.parse(...) can throw and are currently unhandled;
wrap the call that assigns keys in a try-catch around
symmetricDecrypt(reqBody.keys, process.env.CALCOM_APP_CREDENTIAL_ENCRYPTION_KEY
|| "") and JSON.parse(...) (the code that assigns the keys variable), catch
errors, log a non-sensitive error message, and return a safe client error
response (e.g., 400 with a generic "invalid credentials" message) instead of
letting the exception propagate; ensure no sensitive details or stack traces are
returned to the client.
- Around line 17-29: The handler must reject non-POSTs and must not allow a
missing secret to bypass validation: in the exported handler function, first
enforce req.method === "POST" and return 405 for others; then ensure
process.env.CALCOM_WEBHOOK_SECRET is defined (if not, return 403) before
comparing it to the incoming header (use process.env.CALCOM_WEBHOOK_HEADER_NAME
|| "calcom-webhook-secret" to read the header); finally perform the strict
compare between the known secret and the header value and return 403 on
mismatch. Reference: handler, APP_CREDENTIAL_SHARING_ENABLED,
CALCOM_WEBHOOK_SECRET, CALCOM_WEBHOOK_HEADER_NAME.

In `@packages/app-store/_utils/oauth/parseRefreshTokenResponse.ts`:
- Around line 25-27: The code sets refreshTokenResponse.data.refresh_token to
the literal "refresh_token", which masks the absence of a real token; instead,
stop injecting that sentinel: leave refreshTokenResponse.data.refresh_token as
undefined or null when the provider omits it so downstream logic can detect "no
refresh token". Update the conditional in parseRefreshTokenResponse to remove
the assignment and ensure downstream consumers (any code reading
refreshTokenResponse.data.refresh_token) handle undefined/null distinctly from a
real token.
- Around line 5-11: minimumTokenResponseSchema is incorrectly using computed-key
syntax which creates literal strange keys and also drops unknown properties;
replace the object schema with a schema that accepts access_token plus arbitrary
provider fields by defining z.object({ access_token: z.string() }).passthrough()
(or, if you need to enforce numeric expiry values, validate those separately
with z.record(z.number()) or a refinement/transform), and remove the
computed-key entries so expiry/refresh/provider-specific fields are preserved by
parseRefreshTokenResponse.

In `@packages/app-store/_utils/oauth/refreshOAuthTokens.ts`:
- Around line 3-20: refreshOAuthTokens currently returns a raw fetch Response
when APP_CREDENTIAL_SHARING_ENABLED is true but returns the provider-specific
value from refreshFunction() otherwise, causing downstream callers (expecting
AxiosResponse, HubSpot token object, etc.) to break; update refreshOAuthTokens
to always return a normalized contract: call
fetch(process.env.CALCOM_CREDENTIAL_SYNC_ENDPOINT, ...) then await
response.json(), validate/transform that JSON into the same shape(s) your
callers expect (or into a simple common wrapper { provider: string, data: any,
expiryDate?: string, error?: any }), and return that normalized object so code
using refreshFunction(), refreshOAuthTokens, and callers (which inspect
tokenInfo.data, .expiryDate, or .data.error) receive a consistent structure;
keep the refreshFunction() fallback behavior but adapt/normalize its result to
the same contract as well.
- Around line 8-15: Wrap the fetch to
process.env.CALCOM_CREDENTIAL_SYNC_ENDPOINT in a try/catch, check response.ok
after the await fetch, and throw a descriptive error (including response.status
and response.statusText or response body) when not ok; specifically update the
code around the fetch call (the use of fetch, URLSearchParams, and the returned
response) so network errors are caught and a clear error is thrown on non-2xx
responses before returning the successful response or parsed body.

In `@packages/app-store/googlecalendar/lib/CalendarService.ts`:
- Around line 86-93: The Google token refresh call in CalendarService is
assuming a GaxiosResponse shape (res?.data) but refreshOAuthTokens can return a
standard fetch Response when APP_CREDENTIAL_SHARING_ENABLED, so update the
handling around the result of refreshOAuthTokens (the call wrapping
myGoogleAuth.refreshToken and the subsequent use of token.access_token) to
detect and normalize both shapes: if res has a .data property use that,
otherwise parse the fetch Response body (use the existing helper
handleErrorsJson or similar) to extract the JSON and assign it to token before
accessing token.access_token; adjust the code paths around refreshOAuthTokens,
myGoogleAuth.refreshToken, googleCredentials and token to ensure a unified token
object is used.

In `@packages/app-store/hubspot/lib/CalendarService.ts`:
- Around line 177-189: refreshOAuthTokens can return either a Token-like object
or a raw fetch Response when credential sharing is enabled, but
CalendarService.ts immediately reads hubspotRefreshToken.expiresIn (and other
Token fields), causing NaN/undefined behavior; update the code around the call
to refreshOAuthTokens (the invocation that passes
hubspotClient.oauth.tokensApi.createToken) to detect if the result is a fetch
Response and, if so, await response.json() and map/normalize its fields to the
HubspotToken shape (accessToken, expiresIn, refreshToken, etc.) before using
expiresIn to compute expiryDate and before updating credentials; alternatively
add a type guard/assertion to ensure hubspotRefreshToken matches the expected
Token shape and throw/log a clear error if not.

In `@packages/app-store/salesforce/lib/CalendarService.ts`:
- Line 86: In CalendarService, the current check uses response.statusText which
is unreliable; change the condition to use response.ok (or check
response.status) when validating the fetch result: replace the `if
(response.statusText !== "OK") throw new HttpError({ statusCode: 400, message:
response.statusText });` with a check like `if (!response.ok) throw new
HttpError({ statusCode: response.status, message: response.statusText ||
String(response.status) });` so the code throws with the real HTTP status and a
fallback message; update the `response` usage and HttpError construction
accordingly.

In `@packages/app-store/zoho-bigin/lib/CalendarService.ts`:
- Around line 85-94: The call to refreshOAuthTokens is passing credentialId (the
DB PK) but the function expects the user's ID (calcomUserId) — use
credential.userId instead. Modify the code that defines credentialId (and/or the
refreshAccessToken / biginAuth flow) to also carry credential.userId and update
the call to refreshOAuthTokens(..., "zoho-bigin", credential.userId); if
refreshAccessToken or biginAuth currently only accept credentialId, add a
parameter (or attach userId to the credential object) so you can pass
credential.userId through to refreshOAuthTokens.

In `@packages/app-store/zohocrm/lib/CalendarService.ts`:
- Line 219: The token expiry calculation sets zohoCrmTokenInfo.data.expiryDate
incorrectly by adding 60*60 (milliseconds) to Date.now(), producing an expiry
~3.6 seconds away; update the assignment in CalendarService where
zohoCrmTokenInfo.data.expiryDate is set to add milliseconds for one hour
(multiply by 1000) — e.g., replace the current expression with Date.now() + 60 *
60 * 1000 (optionally wrapped in Math.round or Math.floor) so the expiry is one
hour in the future.

In `@packages/app-store/zoomvideo/lib/VideoApiAdapter.ts`:
- Line 104: The call to parseRefreshTokenResponse(…, zoomRefreshedTokenSchema)
in VideoApiAdapter.ts now throws on failure, so the existing if
(!parsedToken.success) block is dead; wrap the parseRefreshTokenResponse call in
a try-catch instead: call parseRefreshTokenResponse and assign to parsedToken
inside try, and in catch log the error (include context like "failed to parse
refresh token") and rethrow or convert to the adapter's expected error/return
form so callers get a clear failure; update any references to parsedToken
afterward to assume a successful parse when no exception was thrown.

In `@packages/lib/constants.ts`:
- Around line 103-104: APP_CREDENTIAL_SHARING_ENABLED currently evaluates to the
raw CALCOM_APP_CREDENTIAL_ENCRYPTION_KEY string when both env vars exist; coerce
the expression to a boolean so the key value is never exposed. Change the
initializer for APP_CREDENTIAL_SHARING_ENABLED to return a strict boolean based
on the presence of CALCOM_WEBHOOK_SECRET and
CALCOM_APP_CREDENTIAL_ENCRYPTION_KEY (e.g., wrap the combined check with
Boolean(...) or use double-negation) so imports of
APP_CREDENTIAL_SHARING_ENABLED cannot leak secret values.